OWASP Secure Coding Practices-Quick Reference Guide

v2.0.1

Guidance on implementing a secure software development framework. 安全な software 開發 framework の實裝に關する手引き

Clearly define roles and responsibilities. 役割と責任を明確にする

Provide development teams with adequate software security training. 開發 team は software security について適切に訓練する

Implement a secure software development lifecycle. 安全な software 開發 lifecycle を實裝する

Establish secure coding standards. 安全な coding 標準を確立する

OWASP Development Guide Project

Build a re-usable object library. 再利用可能な object library を構築する

OWASP Enterprise Security API (ESAPI) Project

Verify the effectiveness of security controls. security. 制禦の有效性を檢證する

OWASP Application Security Verification Standard (ASVS) Project

Establish secure outsourced development practices including defining security requirements and verification methodologies in both the request for proposal (RFP) and contract. 提案依賴書 (RFP) と契約書の兩方で security 要件と檢證方法を定義するなど、安全な外部委託開發慣行を確立する

Secure Coding Practices Checklist

Conduct all data validation on a trusted system (e.g., The server). 信賴する system 上の全ての data 檢證を管理する (例 : server)

Identify all data sources and classify them into trusted and untrusted. Validate all data from untrusted sources (e.g., Databases, file streams, etc.). 全ての data 源を特定し、信賴できる data 源と信賴できない data 源に區別する。信賴できない data 源からの全ての data を檢證する (例 : database、file system 等)

There should be a centralized input validation routine for the application. application には入力の檢證を一箇所で一遍に行ふ仕組みがなければならない

Specify proper character sets, such as UTF-8, for all sources of input. 全ての入力源に UTF-8 等の適切な文字 encoding を指定する

Encode data to a common character set before validating (Canonicalize). 檢證する前に data を共通の文字 encoding に變換する (正規化する)

All validation failures should result in input rejection. 檢證に失敗した data は入力を拒否しなければならない

Determine if the system supports UTF-8 extended character sets and if so, validate after UTF-8 decoding is completed. system が UTF-8 擴張文字集合を利用してもよいとしてゐるか確認し、もし利用してもよいとしてゐるならば UTF-8 の decode が完了してから檢證する

Validate all client provided data before processing, including all parameters, URLs and HTTP header content (e.g. Cookie names and values). Be sure to include automated post backs from JavaScript, Flash or other embedded code. client から受け取った、URL や HTTP header (例 : Cookie の名と値) を含む全ての data を檢證する。この data には JavaScript や Flash や他の埋め込み code から自動送信された data も含まれる事に注意する

Verify that header values in both requests and responses contain only ASCII characters. request と response 雙方の header が ASCII 文字しか含まない事を檢證する

Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect). redirect で受け取った data を檢證する (攻擊者は惡意有る data を redirect target に直接に送信するかもしれず、さうすると redirect の前に實行する application の處理やあらゆる檢證を囘避できる)

Validate for expected data types. 期待する data 型であるか檢證する

Validate data range. data の範圍を檢證する

Validate data length. data の長さを檢證する

Validate all input against a "white" list of allowed characters, whenever possible. 可能な限り、全ての入力を、許可された文字の allow list を使って檢證する

If your standard validation routine cannot address the following inputs, then they should be checked discretely. 標準的に利用する檢證處理が以下の入力に對應できない場合は、個別に檢査しなければならない

(Utilize canonicalization to address double encoding or other forms of obfuscation attacks.) (正規化を行ひ、二重 encoding やその他の難讀化攻撃に對處する)

Conduct all encoding on a trusted system (e.g., The server). 信賴する system 上の全ての encoding を管理する (例 : server)

Utilize a standard, tested routine for each type of outbound encoding. 出力する encoding の種類每に標準の test 濟みの處理を使ふ

Contextually output encode all data returned to the client that originated outside the application's trust boundary. HTML entity encoding is one example, but does not work in all cases. application の信賴境界の外から得た data を client に返す場合は全てを環境に應じて encode する。例へば HTML entity に encode する、ただしそれで全て濟む訣ではない

Encode all characters unless they are known to be safe for the intended interpreter. 出力を解釋する側にとって安全であるとわかってゐない限り、全ての出力を encode する

Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP. SQL、XML 及び LDAP への問ひ合はせに含める、信賴できない全ての data を環境に應じて無害化する

Sanitize all output of un-trusted data to operating system commands. OS command に含める、信賴できない全ての data を無害化する

Require authentication for all pages and resources, except those specifically intended to be public.

全てのページ、リソースに対して認証を要求し、公開する物のみを例外とする

All authentication controls must be enforced on a trusted system (e.g., The server).

全ての認証制御は信頼されたシステムで行わなければならない（例：サーバー）

Establish and utilize standard, tested, authentication services whenever possible.

標準、テストされた認証サービスを可能な限り利用する

Use a centralized implementation for all authentication controls, including libraries that call external authentication services.

認証の集中管理を実装する。外部の認証サービスライブラリを利用する場合も含む

Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control.

認証ロジックと要求されているリソースを分離し、集中化された認証サービスへのリダイレクトを利用する

All authentication controls should fail securely.

全ての認証制御は安全に失敗しなければならない

All administrative and account management functions must be at least as secure as the primary authentication mechanism.

全ての認証管理とアカウント管理機能は少なくとも主たる認証メカニズムと同程度に安全にする

If your application manages a credential store, it should ensure that only cryptographically strong one-way salted hashes of passwords are stored and that the table/file that stores the passwords and keys is write-able only by the application. (Do not use the MD5 algorithm if it can be avoided).

アプリケーションが認証データを保存する場合、暗号理論的に強いハッシュ関数を用い、ソルトと一緒にパスワード保存し、データベーステーブル／ファイルに保存されたパスワード／キーはそのアプリケーションだけが書き込めるようにする（MD5はできる限り利用しない）

Password hashing must be implemented on a trusted system (e.g., The server).

パスワードのハッシュは信頼できるシステムで行う（例：サーバーで行う）

Validate the authentication data only on completion of all data input, especially for sequential authentication implementations.

認証データは全てのデータを取得してからバリデーションを行う。特にシーケンシャル認証を実装する場合には必須

Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code.

認証失敗時のレスポンスにはどの認証データが間違っていたのかを示唆する情報を含めない。例えば、”不正なユーザー名です”や”不正なパスワードです”とは表示せず、単に”ユーザー名かパスワードが不正です”と表示する。エラー時のレスポンスは表示上、コード上（HTML）ともに全く同一でなければならない

Utilize authentication for connections to external systems that involve sensitive information or functions.

機密データを取り扱う外部システムとの接続には認証の仕組みを利用する

Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system (e.g., The server). The source code is NOT a secure location.

外部サービスにアクセスするための認証用のクレデンシャルは保護された信頼できるシステムに暗号化して保存する（例：サーバーに保存する）ソースコードは安全な保存場所ではない

Use only HTTP POST requests to transmit authentication credentials.

認証用のクレデンシャルはHTTPのPOSTメソッドのみを用いて送信する

Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception.

恒久的なパスワードは暗号化された接続または暗号化したデータ、例えば暗号化メール、としてのみ送信する。メールによるパスワードリセット用の一時的なパスワードは例外

Enforce password complexity requirements established by policy or regulation. Authentication credentials should be sufficient to withstand attacks that are typical of the threats in the deployed environment. (e.g., requiring the use of alphabetic as well as numeric and/or special characters)

セキュリティポリシーまたは基準などに従い、複雑なパスワードの利用を強制する。認証クレデンシャルは利用される環境において一般的な脅威と攻撃に十分対応できる物でなければならない。（例：アルファベット、数字および記号の利用を強制するなど）

これは上書きしようねぇ

Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases.

セキュリティポリシーまたは基準などに従い、パスワードの長さを強制する。8文字のパスワードがよく利用されるが、16文字以上が好ましい。または複数の単語を利用するパスフレーズの導入を検討する

（訳注：ユーザーにとって覚えやすい複数の単語を組み合わせて作ったパスフレーズでも、単語数が十分であればランダムパスワードと同等以上の安全性である、とする研究がある）

Password entry should be obscured on the user's screen. (e.g., on web forms use the input type "password")

パスワード入力用のフィールドはユーザー画面上から内容が見えないようにする。（例：Webフォームの場合、inputの種別に”password”を利用する）

Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, but not so long as to allow for a denial-of-service attack to be performed.

決まった回数（5回が一般的）のログイン失敗でアカウントの無効化を行う。パスワードを推測するブルートフォース攻撃を諦めさせる為に十分な時間を設定する。ただし、サービス不能攻撃が可能になるほど長い時間は設定しない。

Password reset and changing operations require the same level of controls as account creation and authentication.

パスワードリセットおよび変更操作はアカウント作成／認証と同じレベルの制御を要求する

Password reset questions should support sufficiently random answers. (e.g., "favorite book" is a bad question because “The Bible” is a very common answer)

パスワードリセットの質問は十分にランダムとなる回答が得られる質問でなければならない。（例：”好きな本”は悪い例。”聖書”と答えるユーザーが多い）

（訳注：私としてはパスワードリセットの秘密の質問の利用はお勧めしません。これはメールアドレスや携帯電話などが利用できない環境を想定した仕組みであまり安全とは言えません）

If using email based resets, only send email to a pre-registered address with a temporary link/password.

メールを利用したパスワードリセットを実装する場合、既に登録済のメールアドレスにのみ一時的なパスワード／URLを送信する

Temporary passwords and links should have a short expiration time.

一時的なパスワード／URLは短い有効期間を持たなくてはならない

Enforce the changing of temporary passwords on the next use.

一時的なパスワードは次の利用でパスワードを変更するよう強制する

Notify users when a password reset occurs.

パスワードのリセットが行われた場合、ユーザーに通知する

Prevent password re-use.

同じパスワードの再利用は禁止する

Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use.

パスワードの再変更には最低1日を要求し、パスワード再利用の攻撃を防止する

Enforce password changes based on requirements established in policy or regulation. Critical systems may require more frequent changes. The time between resets must be administratively controlled.

セキュリティポリシーまたは基準などに従い、パスワードの変更を要求する。重要なシステムの場合はより頻繁な変更を必要とされる。リセットする間隔は管理者が制御できなければならない

（訳注：パスワードの強度が十分に強く他のシステムと共有していない場合、頻繁な変更がリスクに成り得ます。頻繁すぎる更新はユーザーが脆弱なパスワードを設定する原因になります。特にセキュリティリテラシーの低いユーザーにはこの傾向が顕著である点に注意が必要です）

Disable "remember me" functionality for password fields.

パスワードをフィールドでは”自動入力機能”を無効にする

（訳注：このプラクティスには異論があります。私はブラウザにサービス毎に完全にランダムなパスワードを記憶させています。何十文字もあるランダム文字列を記憶／入力するのは無理があります。しかし、共有システムの存在を考慮するとこの要求は妥当です）

The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login.

最後の利用時間（ログイン成功、ログイン失敗）は次のログイン成功時にユーザーに知らせなければならない

Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed.

同じパスワードを利用し、複数のアカウントに対してログインを試行する攻撃を検出する仕組みを構築する。この攻撃はIDが知られていたり、簡単に推測できる場合のアカウントロック機構を回避する攻撃パターンとして知られている。

Change all vendor-supplied default passwords and user IDs or disable the associated accounts.

ベンダーが設定したデフォルトパスワード、IDは全て変更する、またはこれらのアカウントを無効にする

Re-authenticate users prior to performing critical operations.

重要な操作を行う場合、ユーザーに再認証を要求する

Use Multi-Factor Authentication for highly sensitive or high value transactional accounts.

重要なアカウント、トランザクションには多要素認証を利用する

If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code.

認証に外部ライブラリを利用する場合、不正なコードが含まれていないか慎重に検証／検査する

Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid

サーバーまたはフレームワークのセッション管理を利用する。アプリケーションはこれらのセッション管理システムが生成したIDのみで妥当だと識別しなければならない。

※擴張していけない訣ではない

Session identifier creation must always be done on a trusted system (e.g., The server)

セッションIDの生成は常に信頼できるシステム上で行う（例：アプリが動作するサーバーで生成する）

Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers

セッション管理機構は十分にランダムなIDが生成可能であるよう、緻密に検証されたアルゴリズムを利用する

Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site

認証済みセッション用のクッキーにはサイトにとって適切な範囲に制限するドメインとパス属性を設定しなければならない

Logout functionality should fully terminate the associated session or connection

ログアウト機能は関連するセッション／接続を完全に破棄させなければならない

Logout functionality should be available from all pages protected by authorization

ログアウト機能は全ての認証済みページで利用できなければならない

Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours

リスクとビジネス的な機能のバランスを考えて、セッションの有効期限（タイムアウト）はできる限り短く設定する。ほとんどの場合、数時間以上のセッションを許可してはならない

Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts

継続的なログインを許可せず、セッションがアクティブでも定期的にセッションを破棄する。特に多数のサービスに接続するアプリケーションや重要なシステムではこのような処理が必要です。破棄までの時間はビジネス要求を満し、ユーザーからの苦情を緩和するためにユーザーが十分な情報を得られるようにする

If a session was established before login, close that session and establish a new session after a successful login

もしログイン前のセッションがある場合、そのセッションは破棄しログイン成功時に新しいセッションを作らなければならない

Generate a new session identifier on any re-authentication

再認証時には必ず新しいセッションIDを生成しなければならない

Do not allow concurrent logins with the same user ID

同じユーザーIDでの同時接続を許さない

（訳注：これは多くの一般的Webサイトでは難しいと思います。しかし、金融機関などのサイトではこのような制限は必要です）

Do not expose session identifiers in URLs, error messages or logs. Session identifiers should only be located in the HTTP cookie header. For example, do not pass session identifiers as GET parameters

セッションIDをURL、エラーメッセージ、ログに記載しない。セッションIDはHTTPのクッキーヘッダでのみ利用する。例えば、セッションIDをGETメソッドのパラメータとして利用してはならない

Protect server side session data from unauthorized access, by other users of the server, by implementing appropriate access controls on the server

サーバー側のセッションデータは許可のないユーザー／アプリケーションからアクセスできないよう適切なアクセス制御をサーバー上で実装し保護する

Generate a new session identifier and deactivate the old one periodically. (This can mitigate certain session hijacking scenarios where the original identifier was compromised)

定期的に新しいセッションIDを生成し、古いセッションIDを破棄する（この操作は元のセッションIDが漏洩した場合など、セッションハイジャックの緩和策となる）

（訳注：セッションIDを盗んだ攻撃者が有効なセッションIDを取得する場合もありますが、正当なユーザーも突然ログアウトした状態になるため、セッションハイジャックに気づく切っ掛けになる。古いセッションは即座に削除しない。タイムスタンプを利用した有効期限管理が必要です）

Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication. Within an application, it is recommended to consistently utilize HTTPS rather than switching between HTTP to HTTPS.

HTTPからHTTPSに接続が変更された場合、新しいセッションIDを生成する。これは認証時に発生する場合がある。アプリケーション内ではHTTPとHTTPSを切り換えることなく、常にHTTPSを利用することが望ましい

Supplement standard session management for sensitive server-side operations, like account manage- ment, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks

サーバー側での機密データの取り扱いにセッションを利用する。例えば、アカウント管理などにはセッション単位に保存された強いランダムトークン／パラメータを利用する。この方法でCSRF攻撃を防止できる

Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters

サーバー側での非常に機密性の高いデータの取り扱いや操作にセッションを利用し、セッション単位ではなく、リクエスト単位、強いランダムトークン／パラメータを利用する

Set the "secure" attribute for cookies transmitted over an TLS connection

TLS（HTTPS）接続のクッキーには”secure”属性を指定する

Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie's value

HttpOnly属性をクッキーに指定する。ただし、クライアント側のスクリプトがクッキーの値を参照／変更する必要がある場合は除く

Use only trusted system objects, e.g. server side session objects, for making access authorization decisions

信用可能なシステムオブジェクトのみ利用する（例：サーバー側のセッションオブジェクトのみを認証の判断に利用する）

Use a single site-wide component to check access authorization. This includes libraries that call external authorization services

単一かつシステム全体のアクセス許可コンポーネントを利用する。これには外部認証サービスを行うライブラリも含める

Access controls should fail securely

アクセス制御は安全に失敗しなければならない

Deny all access if the application cannot access its security configuration information

アプリケーションがセキュリティ設定情報にアクセスできない場合、全てのアクセスを拒否する

Enforce authorization controls on every request, including those made by server side scripts, "includes" and requests from rich client-side technologies like AJAX and Flash

全てのリクエストに対して認可の制御（アクセス制御）を強制する。これにはサーバーサイドスクリプト、AJAXやFlashのリクエストも含める

Segregate privileged logic from other application code

特権機能と他のアプリケーション機能を分離する

Restrict access to files or other resources, including those outside the application's direct control, to only authorized users

ファイルや他のリソースへのアクセスを制限する。アプリケーションが直接制御しないファイルを含め、許可されたユーザーのみがアクセスできるようにする

Restrict access to protected URLs to only authorized users

許可されたユーザーのみが保護されたURLにアクセスできるよう制限する

Restrict access to protected functions to only authorized users

許可されたユーザーのみが保護された機能にアクセスできるよう制限する

Restrict direct object references to only authorized users

許可されたユーザーのみが直接オブジェクトを参照できるよう制限する

Restrict access to services to only authorized users

許可されたユーザーのみがサービスにアクセスできるよう制限する

Restrict access to application data to only authorized users

許可されたユーザーのみがアプリケーションデータにアクセスできるよう制限する

Restrict access to user and data attributes and policy information used by access controls

許可されたユーザーのみがユーザーおよび属性データおよびポリシー情報にアクセスできるよう制限する

Restrict access security-relevant configuration information to only authorized users

許可されたユーザーのみがセキュリティ関連の設定情報にアクセスできるよう制限する

Server side implementation and presentation layer representations of access control rules must match

サーバー側の実装とプレゼンテーションレイヤーの表示はアクセス制御ルールと一致しなければならない

If state data must be stored on the client, use encryption and integrity checking on the server side to catch state tampering.

クライアントサイドに状態データを保存しなければならない場合、暗号を用い、改竄を防ぐための完全性チェックをサーバー側で行う

（訳注：エラー発生時の対処はビジネスルールとして定義されている。例えば、ゲームなどの場合はデータ取得エラーや計算エラーは無視して処理を進め、会計関連の場合は致命的エラーとして対処するなど）

Enforce application logic flows to comply with business rules

アプリケーションロジック問題はビジネスルールに適合するよう強制する

Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks

一定時間の間に単一ユーザーまたはデバイスが実行可能なトランザクションを制限する。上限のトランザクション数／間隔は実際のビジネス要求を上回っていなければならないが、自動的な攻撃の効果を無くす程度に低くなけばならない。

Use the "referer" header as a supplemental check only, it should never be the sole authorization check, as it is can be spoofed

“REFERER”ヘッダは追加のチェックとしてのみ利用する。REFERERヘッダは改竄可能であり、REFERERのみで認証することは決して行わない。

If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate

長い時間のセッションが許可されている場合、定期的にユーザーの認可情報をチェックし、権限が変更されていないか再バリデーションし、変更されている場合はユーザーをログアウトさせ、再認証させる

Implement account auditing and enforce the disabling of unused accounts (e.g., After no more than 30 days from the expiration of an account’s password.)

アカウント監査機能を実装し、未使用アカウントの無効化を行う（例：例えば、アカウントのパスワード期限が失効してから30日後から無効とするなど）

The application must support disabling of accounts and terminating sessions when authorization ceases (e.g., Changes to role, employment status, business process, etc.)

アプリケーションは許可の取り消しなどの処理の為にアカウントの無効化とセッションの廃棄をサポートしなければならない。（例：役割の変更、雇用状態の変化、ビジネスプロセスの変化、など）

Service accounts or accounts supporting connections to or from external systems should have the least privilege possible

サービスアカウントまたは外部へ／内部への接続を行うアカウントは必要最小限の権限のみ持たせる

Create an Access Control Policy to document an application's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources

アプリケーションのビジネスルールをドキュメント化し、システムにアクセスできるデータ種別やアクセス許可の分類／プロセスが適切に提供され制御できる、アクセス制御ポリシーを作成する。これにはデータおよびシステムリソースへのアクセス要求を識別し含める。

All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system (e.g., The server)

アプリケーションユーザーから秘密保護目的に利用する全ての暗号機能は必ず信頼できるシステム（例：サーバー）上で利用する

Protect master secrets from unauthorized access

マスターとなる秘密鍵などを許可のないアクセスから守る

Cryptographic modules should fail securely

暗号モジュールは安全に失敗しなければならない

All random numbers, random file names, random GUIDs, and random strings should be generated using the cryptographic module’s approved random number generator when these random values are intended to be un-guessable

ランダム値が推測されてはならない場合、全てのランダム数値、ランダムファイル名、ランダムGUIDとランダム文字列は暗号モジュールの検証されたランダムナンバー生成器（RNG）を利用する

Establish and utilize a policy and process for how cryptographic keys will be managed

どのように暗号鍵を管理するか、利用ポリシーとプロセスを確立し利用する

Do not disclose sensitive information in error responses, including system details, session identifiers or account information

エラー表示に秘密の情報を含めない。これにはシステム情報、セッションID、アカウント情報などが含まれる

Use error handlers that do not display debugging or stack trace information

デバッグ情報、スタックトレース情報を含めないエラーハンドラーを利用する

（訳注：当然ですが開発時にこれらの情報を含めることには問題はない）

Implement generic error messages and use custom error pages

一般的なエラーメッセージにカスタムエラーページを実装する

（訳注：フレームワークやWebサーバーのエラーメッセージやエラーページを利用しない）

The application should handle application errors and not rely on the server configuration

アプリケーションはサーバーの設定を頼りにせず、アプリケーションのエラーを処理する

Properly free allocated memory when error conditions occur

エラーが発生した場合、適切に割り当て済みメモリを解放する

Error handling logic associated with security controls should deny access by default

セキュリティ制御に関連するエラー処理ロジックはデフォルトでアクセスを拒否する

All logging controls should be implemented on a trusted system (e.g., The server)

全てのログ機能は信頼されたシステム（例：サーバー）で実装する

Logging controls should support both success and failure of specified security events

ログ機構はセキュリティイベントの成功／失敗両方をサポートする

Ensure logs contain important log event data

ログが重要なイベントデータを記録することを保証する

Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software

信頼できないデータが含まれるログをビューワーやソフトウェアを利用して参照する場合にコードとして実行されないようにする

Restrict access to logs to only authorized individuals

許可された個人のみにログへのアクセスを許可する

Utilize a master routine for all logging operations

ログ操作に統一したライブラリ関数を利用する

Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords

機密扱いのデータをログに保存しない。これには不必要なシステムの詳細情報、セッションIDやパスワードなどが含まれる

Ensure that a mechanism exists to conduct log analysis input validation failures

ログ分析を行う機構があることを保証する

Log all input validation failures

全ての入力バリデーションの失敗をログする

Log all authentication attempts, especially failures access control failures

全ての認証要求、特に失敗をログする

Log all access control failures

全てのアクセス制御の失敗をログする

Log all apparent tampering events, including unexpected changes to state data

予期しない状態データの変化を含む、全てのデータ改竄イベントをログする

Log attempts to connect with invalid or expired session tokens

全ての無効または期限切れのセッションIDでの接続をログする

（訳注：PHPのセッションモジュールを普通に使っていてはできません。検討します）

Log all system exceptions

全ての例外をログする

Log all administrative functions, including changes to the security configuration settings □ Log all backend TLS connection failures

セキュリティ設定の変更も含み、全ての管理者機能のログする。

Log cryptographic module failures

全てのTLS接続失敗をログする

Use a cryptographic hash function to validate log entry integrity

ログエントリの完全性をバリデーションする為、暗号理論的ハッシュ関数を利用する

Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks

最小権限の原則、ユーザーにはタスクを実行するために必要な機能、データおよびシステムのみへのアクセスに制限、を実装する

Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required.

サーバーに保存された全ての機密データのキャッシュや一時的コピーを許可されていないアクセスから保護し、一時的なコピーは必要とされなくなった時点で廃棄する

Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see "Cryptographic Practices" for additional guidance

認証関連データなど非常に気密性の高いデータはサーバー側であっても暗号化する。常によく検証されたアルゴリズムを利用する。”暗号の取り扱い”を追加のガイドとして参照

Protect server-side source-code from being downloaded by a user

サーバー側のソースコードがユーザーからダウンロードされないよう防ぐ

Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically secure manner on the client side. This includes embedding in insecure formats like: MS viewstate, Adobe flash or compiled code

パスワード、接続文字列やその他の気密性のある情報をクリアテキストで保存したり、暗号理論的に安全でない方法でクライアント側に保存しない。これらには安全ではないMSビューステート、Adobe Flashやコンパイルされたコードなども含まれる

Remove comments in user accessible production code that may reveal backend system or other sensitive information

ユーザーがアクセス可能なコードからコメントを削除する。これらのコメントはバックエンドの機密情報が含む場合もある

Remove unnecessary application and system documentation as this can reveal useful information to attackers

不必要なアプリケーションやシステムドキュメントを削除する。これらは攻撃者に有用な情報を与えることがある

Do not include sensitive information in HTTP GET request parameters

HTTP GETリクエストのパラメータに機密情報を含めない

Disable auto complete features on forms expected to contain sensitive information, including authentication

機密情報を含むページ、認証ページ含む、では自動入力機能を無効にする

Disable client side caching on pages containing sensitive information. Cache-Control: no-store, may be used in conjunction with the HTTP header control "Pragma: no-cache", which is less effective, but is HTTP/1.0 backward compatible

機密情報を含むページではクライアント側のキャッシュを無効にする。より効果が低いCache-Control: no-storeをHTTP/1.0互換性の為に、Pragma: no-cacheを一緒に利用する

The application should support the removal of sensitive data when that data is no longer required. (e.g. personal information or certain financial data)

アプリケーションはデータが必要に無くなった場合に備え、機密データを削除できなければならない

Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users

サーバーに保存された機密データに対する適切なアクセス制御を実装する。これらには特定のシステムユーザーによってのみアクセスできるキャッシュデータ、一時ファイルのデータを含む

Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the connection and may be supplemented by discrete encryption of sensitive files or non-HTTP based connections

機密データの送信には暗号を実装する。HTTP通信では機密ファイルは暗号は暗号化し、TLS通信の場合でも追加の暗号として用いる

TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate certificates when required

TLS証明書は正当でなければならず、正しいドメインであり、有効期限内で中間証明書が必要な場合は一緒にインストールされていなければならない

Failed TLS connections should not fall back to an insecure connection

TLS接続に失敗した接続は安全でない接続にフォールバックしてはならない

Utilize TLS connections for all content requiring authenticated access and for all other sensitive information

認証が必要なアクセスとその他機密情報を扱うコンテンツ全てにTLS接続を利用する

Utilize TLS for connections to external systems that involve sensitive information or functions

機密情報を含む外部システムの接続にTLS接続を利用する

Utilize a single standard TLS implementation that is configured appropriately

適切に設定された単一の標準TLS実装を利用する

Specify character encodings for all connections

全ての接続で文字エンコーディングを指定する

Filter parameters containing sensitive information from the HTTP referer, when linking to external sites

外部システムにアクセスする場合、HTTP REFERERから機密情報を含むパラメータをフィルターする

Ensure servers, frameworks and system components are running the latest approved version

サーバー、フレームワークおよびシステムコンポーネントが最新バージョンであることを保証する

Ensure servers, frameworks and system components have all patches issued for the version in use

サーバー、フレームワークおよびシステムコンポーネントがバージョンに対応した全てのパッチが適用されていることを保証する

Turn off directory listings

ディレクトリリスティングを無効化する

Restrict the web server, process and service accounts to the least privileges possible

Webサーバー、プロセスとサービスアカウントの権限を可能な限り最小限にする

When exceptions occur, fail securely

例外が発生した場合、安全に終了する

Remove all unnecessary functionality and files

全ての不必要な機能とファイルを削除する

Remove test code or any functionality not intended for production, prior to deployment

テストコードや運用時に必要ない機能はデプロイ前に全て削除する

Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then "Disallow" that entire parent directory in the robots.txt file rather than Disallowing each individual directory

サーチエンジンなどでのインデックスを防ぐためのrobots.txtファイルによってディレクトリ構造が漏れないようにする。公開しないディレクトリは１つのディレクトリにまとめ、個々のディレクトリ設定とせず、１つのディレクトリを指定するだけで良いディレクトリ構成にする。

Define which HTTP methods, Get or Post, the application will support and whether it will be handled differently in different pages in the application

アプリケーションがGETまたはPOSTのどちらをサポートするのか定義し、異るページでは異る処理が行われることを明確にする。

Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism

WebDAV拡張など不必要なHTTPメソッドは無効にする。もしファイル処理にHTTP拡張メソッドが必要な場合、良く検証された認証機構を利用する

If the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar manor or insure that you understand any difference that may exist (e.g. handling of extended HTTP methods)

WebサーバーがHTTP 1.0と1.1の両方をサポートする場合、両方が同じように設定されていることを保証する。開発者が違いがあることを理解していることを保証する。（例：拡張HTTPメソッドの処理など）

Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks

HTTPレスポンスヘッダーからOS、Webサーバーバージョン、アプリケーションフレームワークなど、不必要な情報を削除する

The security configuration store for the application should be able to be output in human readable form to support auditing

アプリケーションのセキュリティ設定関連の情報は監査の為に人が読める形式の出力をサポートしなければならない

Implement an asset management system and register system components and software in it

資産管理システムを実装し、システムコンポーネントとソフトウェアを登録する

Isolate development environments from the production network and provide access only to authorized development and test groups. Development environments are often configured less securely than production environments and attackers may use this difference to discover shared weaknesses or as an avenue for exploitation

開発環境は運用ネトワークから分離し、許可された開発とテストグループにのみアクセスを許可する。開発環境は運用環境より安全でない設定であることが多く、攻撃者は違いを共通する弱点の発見に利用したり、攻撃へ導いたりする

Implement a software change control system to manage and record changes to the code both in development and production

ソフトウェアの変更管理システムを導入し、開発環境／運用環境両方の変更を記録／管理する

（訳注：gitなどのバージョン管理システムを導入する。DBを用いた構成管理を行う）

Use strongly typed parameterized queries

強い型付けのプリペアードクエリを利用する

（訳注：SQLiteのデータ型は特殊なので、SQLiteでは特に重要。ただし、データベースのデータ型で表現可能な範囲を制限するようなデータ型の強制、例えば64ビット整数のカラムに32ビット整数を強制すると別の問題が発生する。不用意な強い型付けはNG）

Utilize input validation and output encoding and be sure to address meta characters. If these fail,　do not run the database command

入力バリデーションと出力エンコーディングを利用する。メタ文字（意味を持つ文字）に対応していることを保証する。もしこれらが失敗した場合、データベースコマンドを実行してはならない

（訳注：メタ文字はSQL文とは限らない。現在のDBはJSON、XML、正規表現など様々なシステムをサポートし、それぞれに意味がある文字がある）

Ensure that variables are strongly typed

変数が強い型付けであることを保証する

（訳注：無条件に強い型付けにすれば良いものではありません）

The application should use the lowest possible level of privilege when accessing the database

データベースにアクセスする場合、アプリケーションは最も低い権限でアクセスする

（訳注：理想的には検索しか行わない場合、読み込み権限のみを持つ接続でアクセスする方が良い。現実にはアクセスが多いサイトの場合、データベース接続数が2倍以上になるので難しい場合が多いが、リードオンリーのレプリカにアクセスする、などの対策は取れる）

Use secure credentials for database access

データベースアクセスには安全なクレデンシャルを利用する

Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted.

接続文字列はアプリケーション内にハードコードしない。接続文字列は信頼できるシステム上の別の設定ファイルに保存し、これらは暗号化する

Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database

データアクセスはストアードプロシージャーを利用して抽象化し、データベースのベーステーブルのアクセス権限の削除を許可する

（訳注：直訳で解りずらいですが、ストアドプロシージャーのみに権限を与え、テーブルにアクセス権限を与えない、ということです）

Close the connection as soon as possible

接続が不必要になったら即座に切断する

（訳注：永続的接続を使うな、ということではありません）

Remove or change all default database administrative passwords. Utilize strong passwords/phrases or implement multi-factor authentication

全てのデフォルトのデータベース管理者パスワードを変更するか削除する。強いパスワード／パスフレーズを利用するか、多要素認証を実装する

Turn off all unnecessary database functionality (e.g., unnecessary stored procedures or services, utility packages, install only the minimum set of features and options required (surface area reduction))

不必要なデータベース機能を無効にする（例：不必要なストアードプロシージャーやサービス、ユーティリティパッケージ、最低限必要な機能とオプションをインストールする（攻撃可能範囲の削減））

Remove unnecessary default vendor content (e.g., sample schemas)

不必要なデフォルトのベンダーコンポーネントを削除する（例：サンプルスキーマ）

Disable any default accounts that are not required to support business requirements

全てのデフォルトアカウントを無効にする。例外はビジネス要求に必要な場合

The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)

アプリケーションはそれぞれの信頼区分に応じて異るクレデンシャルでデータベースにアクセスする（例：ユーザー、リードオンリー ユーザー、ゲスト、管理者）

Do not pass user supplied data directly to any dynamic include function

あらゆる動的インクルード関数に対してユーザーが送信したデータを直接渡さない

（訳注：全てのファイルを開く関数でユーザーが送信したデータを渡さない）

Require authentication before allowing a file to be uploaded

ファイルアップロードの前に認証を要求する

Limit the type of files that can be uploaded to only those types that are needed for business purposes

ビジネスの目的の必要なファイルタイプのみアップロードできる可能なファイルを制限する

Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient

ファイルヘッダーをチェックしてアップロードされたファイルタイプが期待する物であるかバリデーションする。拡張子のチェックだけでは不十分

Do not save files in the same web context as the application. Files should either go to the content server or in the database.

アプリケーションと同じWebコンテクストにファイルを保存しない。ファイルはコンテンツサーバーかデータベースのどちらかに保存する

Prevent or restrict the uploading of any file that may be interpreted by the web server.

Webサーバーによって実行される可能性のあるファイルのアップロードを禁止または制限する

Turn off execution privileges on file upload directories

アップロードディレクトリのファイルの実行権限は削除する

Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment

UNIX環境では目的のファイルディレクトリをアソシエイテッドパスを使った論理ドライブとしてマウントするかchroot環境を利用し、安全なアップロードを可能にする

When referencing existing files, use a white list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead

存在するファイルを参照する場合、許可するファイル名と拡張子のホワイトリストを利用する。渡されるパラメータはバリデーションし、期待する値と異る場合は拒否するか、その値を使わずにハードコードされたデフォルト値を利用する

Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs

ユーザーから渡されたデータを動的リダイレクトに利用しない。もしこれを許可しなければならない場合、バリデーションされた物のみか相対URLパスのみ受け入れる

Do not pass directory or file paths, use index values mapped to pre-defined list of paths

ディレクトリやファイルパスを渡さない。定義済みのパスリストのインデックス値を利用する

Never send the absolute file path to the client

決して絶対パスをクライアントに送らない

Ensure application files and resources are read-only

アプリケーションファイルとリソースが読み込み専用であることを保証する

（訳注：最近のアプリは自動更新やアプリからのインストールをサポートしているので困難になりつつあるが、これらのシステムでも不可能ではない）

Scan user uploaded files for viruses and malware

ユーザーがアップロードしたファイルにウィルス／マルウェアが含まれないかスキャンする

Utilize input and output control for un-trusted data

信用できないデータには入力と出力制御を行う

Double check that the buffer is as large as specified

バッファサイズが指定されたサイズと同じか確実にチェックする

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string

コピーするバイト数を指定できる関数、strncpy()など、を利用する場合、コピー先バッファサイズがコピー元バッファサイズと同じであるよう注意する。ヌル文字で終端されている文字列とは限らない

Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space

関数がループで呼ばれている場合、既に割り当て済みメモリへの書き込みが安全であることを確認し、バッファのバウンダリをチェックする

Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions

全ての入力文字列はコピーや連結する前に、合理的な長さに切り詰める

Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)

明示的にリソースをクローズし、ガーベッジコレクションに頼らない（例：接続オブジェクト、ファイルハンドル、など）

Use non-executable stacks when available

利用可能な場合、コード実行不可なスタックを使う

Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.)

脆弱な関数として知られている関数は避ける（例：printf、strcat、strcpyなど）

Properly free allocated memory upon the completion of functions and at all exit points

関数が完了する際に全ての終了箇所で割り当て済みのメモリを適切に解放する

Use tested and approved managed code rather than creating new unmanaged code for common tasks

一般的タスクには管理されていない新しいコードを作るより、テスト／保証されたコードを利用する

Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands directly to the Operating System, especially through the use of application initiated command shells

OSのタスクを実行する場合、特定のタスクに設計されたAPIを利用する。アプリケーションからOSに、特にアプリケーションからシェルを使ったコマンドは、直接実行させない

Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files

インタープリタコード、ライブラリ、実行ファイルと設定ファイルにはチェックサムやハッシュを用いて完全性のチェックを行う

（訳注：この種の処理にはHMACを利用すると良い）

Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions

同時の複数リクエストを防止するためロックを利用するかレースコンディションを防止するための同期メカニズムを利用する

Protect shared variables and resources from inappropriate concurrent access

共有変数やリソースは不適切な同時アクセスから保護する

Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage

全ての変数やデータ保存場所は、宣言するか最初の利用の直前に、明示的に初期化する

In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible

アプリケーションが昇格した権限で動作しなければならない場合、権限の昇格はできる限り遅くし、権限の降格はできる限り早くする

Avoid calculation errors by understanding your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a- number" calculations, and how your language handles numbers that are too large or too small for its underlying representation

プログラミング言語がサポートするデータ型とどのように数値計算が行われるがを理解し、計算エラーを回避する。バイトサイズの不一致、プレシジョン（精度）、符号付き／符号無しの違い、丸め、型変換とキャスト、数値以外（NaN）計算、データ型に対して大きすぎる／小さすぎる場合に言語がどのように処理するかに大きな注意を払う

（訳注：これはデータ型が弱いスクリプト系言語であっても、正しくコードが実行されることを保証するために重要な要素です）

Do not pass user supplied data to any dynamic execution function

ユーザー入力をいかなる動的実行関数にも与えない

Restrict users from generating new code or altering existing code

ユーザーが新しいコードや既存のコードを変更することを制限する

Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality, as these can introduce new vulnerabilities

全ての契約によって作られたアプリケーション、サードパーティコードとライブラリはビジネス要求を満たすか、機能が安全か検証するかレビューする。これらは新しい脆弱性導入の原因となる

Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server

安全な更新を実装する。アプリケーションが自動更新を利用する場合、暗号理論的な署名をコードに利用し、ダウンロードしたクライアントが署名を確認することを保証する。コードを保存するサーバーからの転送には暗号通信を利用する

入力値のバリデーション

バリデーション

サニタイズ

出力のエンコーディング

XSS - クロスサイトスクリプティング

SQL インジェクション

認證とパスワードの管理

認證情報の傳達

認證情報のバリデーションと保存

パスワードポリシー

その他のガイドライン

セッション管理

アクセスコントロール

擬似亂數の生成

エラー處理とロギング

エラー處理

ロギング

データの保護

通信のセキュリティ

HTTP/TLS

WebSocket

システム構成

データベースのセキュリティ

接續

認證

パラメータライズドクエリ

ストアドプロシージャ

ファイル管理

メモリ管理

一般的なコーディングプラクティス

クロスサイトリクエストフォージェリ